第 2 層：流程閘道。

這一層講的不是「規則內容」，而是「做事的順序」。

我認為這是最多團隊做錯的一層。配置都對，順序錯了，所以沒效。

那個案子配了什麼

先看配置。單看清單，那個案子的 AI 工具設定相當完整：

自訂 agent 角色      10 個，合計 1,713 行設定
Reviewer skill        5 個
兩套 AI 工具並用
權限授權            50+ 條

十個角色包括：後端開發、前端開發、全端、QA、API 測試、專案經理、現代化架構師、前後端契約驗證、UI/UX 設計、BFF 開發。

看起來像一個完整的虛擬開發團隊。

但效果呢？跟這張清單差很多。問題出在底下三個假設。

假設一：通用角色 ≠ 案型專屬角色

這十個 agent 是照「軟體工程通用角色」配的，不是照「這個案子的性質」配的。兩個最明顯的例子：

UI/UX 設計師（42 行）
職責寫的是「進行使用者研究並定義設計策略」「製作 wireframe、mockup 與互動原型」「發展完整的設計系統」。

但這個案子不是在設計新產品，是在對齊舊系統既有的 UI。wireframe？設計稿早就有 58 份了。使用者研究？使用者已經用了十年。設計系統？規格就是那個十年前的樣子。

這個 agent 的每一項職責，對這個案子都毫無幫助。 而且更糟——它的存在會鼓勵「設計」而不是「對齊」，剛好助長了 Day 06 講的過度生成。那該配什麼？大概是這樣：

名稱：UI 規格對齊器
職責：
- 比對新系統元件與舊系統頁面 + 設計稿
- 找出不一致（多餘欄位、缺漏欄位、按鈕位置、預設值、欄位順序）
- 不做任何「改善」建議，只做「對齊」報告
- 輸出 diff 形式的落差清單

注意「不做任何改善建議」這條。這是故意加的限制。這個案子要的是對齊，不是變好。

BFF 開發者（32 行）
BFF（Backend For Frontend）是替前端畫面把後端資料先整理打包好的那一層。這個更直接：這個專案根本沒有 BFF。

32 行設定描述一個不存在的東西。

假設二：先寫後審 vs 先審後寫

五個 reviewer skill 設計得其實不錯。涵蓋端到端、SQL、架構遷移、業務邏輯、UI、權限六個面向。

但實際的用法是：

AI 產出程式碼  →  用 reviewer 找 bug

先寫後審。

正確的用法應該是：

用 reviewer 確認規格  →  AI 才產出程式碼

先審後寫。

這個順序差在哪？

先寫後審，reviewer 的角色是「找出已經犯的錯」。程式碼已經寫了，錯誤也已經在裡面了，reviewer 是在收拾善後。而且找到之後還要改，一改可能又帶出新的問題。

先審後寫，reviewer 的角色是「確認這件事該怎麼做」。它在程式碼還不存在的時候就把規格釘住，錯誤根本沒有機會發生。

回到 Day 12 那條光譜：先寫後審是 detective（事後抓到），先審後寫比較接近 preventive（事前擋掉）。

同一個工具、同樣的內容，只是換了位置，就跨了兩格。

假設三：快到沒空退一步想

第三個問題最隱蔽。

那個案子的開發指令裡有一條：「一次處理五個」。搭配十二輪的修復迴圈，意思是 AI 一個下午可以修六十個問題單。

聽起來是效率。

**但這個速度下，沒有人有空去想「這五個是不是同一個 bug 的五個分身」。**Day 03 講過那個結果：35 張單其實是 18 個 bug，日期類問題在三個月裡修了 20 次。

修一個、漏八個。下一輪測試同類問題又冒出來。

我後來把它寫成一句話：

AI 自動開發的節奏，壓過了思考的節奏。

這不是 AI 的問題，是流程設計的問題。「一次處理五個」這條指令本身，就決定了不會有人退一步問「這五個是不是同一件事」。

那第 2 層該怎麼設計

流程閘道的核心是強制節奏：在正確的時間點，插入正確的動作。實務上有這幾種做法。

一、先計畫、再動手（Plan-then-Execute）

強制 AI 先把計畫寫出來、等人核可，才動手實作。

那個案子有 agent、有 skill，唯獨缺了這個。它可能是最便宜、效果最好的一道閘——計畫階段的修正成本，比程式碼階段低一個量級。

二、高風險的事交給專責角色

例如「任何涉及資料庫結構的改動，必須由 DBA 審查角色執行」。這不是禁止，是改變由誰來做。

三、把常做的事固定成指令

把重複的工作包成一個明確的入口（例如 /新增端點 <模組> <動作>），強制走規範流程。好處是：流程被寫進工具裡，不用靠人記得。

四、規格先行

這是我認為第 2 層最強的一招，強到它值得單獨講：

先把規格寫對、可驗證、可追溯，AI 才被允許動手。
規格本身就是緊箍咒——
只要 spec 沒寫「這個欄位必填」，AI 就不該幫你補必填。

它厲害的地方，在於換了一種管法：不是去列「不可以做什麼」（那有無限多條），而是明確講清楚「要做什麼」（有限，而且驗得出來）。

Day 09 講過「AI 會用先驗補空白」——先驗就是它從過去看過的那些專案帶來的既定印象。**規格就是那個空白的填充物。**空白被填滿了，既定印象就沒有縫隙鑽進來。

（這是 Part 2 的主題，那邊有一個跑了 43 次、一次通過率 36/37 的實例。）

為什麼第 2 層仍然是 advisory

要老實說：這一層還是 advisory——講了，但攔不住。

Plan mode 可以被跳過、指令可以不用、規格可以寫得很鬆。它改變的是順序和形式，不是強制力。

但它的價值在於：好的順序會讓後面幾層的成本大幅下降。

先審後寫，第 4 層要驗的東西就少了。規格先行，第 3 層的檢查就有了對照基準。

第 2 層是槓桿，不是閘門。

小結

• 十個 agent、五個 skill 的配置形式都在，效果沒有，因為角色是照通用軟體工程配的，不是照這個案子配的
• 先寫後審 vs 先審後寫：同一個工具換個位置，跨了兩格光譜
• 「一次處理五個」快到沒人退一步想，於是修一個漏八個
• 第 2 層仍是 advisory，但它是槓桿——好的順序讓後面幾層變便宜

明天講第 3 層。那是那個案子完全沒設置的一層，也是最值得補的一層。